
overall simplified cost is c(jitter) + (latency).
what should the balance between variance and delay be?
	continuous rendering and no input (video): delay is fine, variance is bad. drop the delay term as insignificant (c ~ 1000).
	continuous rendering and responsive input (most games): a balance is needed. low delay = respond quickly, low variance = respond accurately. (c ~ 10)
	sporadic rendering (static webpages, reaction time tests): delay is bad, variance is fine up to input lag, which is huge enough to not matter. (c ~ 1/3, from 40ms reaction time variance). these estimated c might be off by about 3x.

behavior:
	tearing (compositing disabled. usually with fullscreen). missing the timepoint leads to some small tearing at the bottom. cost is proportional to miss amount.
	full frames only (compositing enabled). missing the timepoint leads to a completely delayed frame. cost is a constant for even tiny misses.

a [0, 2] interval has variance 1/3. dropped frames are very noticeable.
basically, how many dropped frames are you willing to tolerate for a 1 frame delay? it's less than 1/60 for sure. at fewer than 1/60 drops, each dropped frame contributes significantly to variance and not so much to delay.
	but, 30fps is less noticeable than 60 fps with frame drops? well, not really.
	according to human measurement.txt, my click timing is like sqrt(112^2 - 38^2)/145*sqrt12 * 1000/60 = 42ms uniform distribution. reaction time distribution is similar. this is for user input.
	note that delay causes variance in user input.
	but vision is different and can tell small differences when interpreting motion. so the intrinsic variance of vision is nearly zero. that means that standard deviation is the right thing to base costs on, not variance
